fix(gate): cancel PR runs only for new commits - #71

Summary

A newer run on the same commit (for editing the description, marking the pull request ready, reopening it; e.g. Sourcery editing the body) cancelled the CI run in progress. Its gate (passed, "CI passed", if: always()) then failed on the jobs the cancellation stopped, and as the newest check run of a name on a commit counts, that failure blocked the merge (cloud-registry-ui#242: run 42668413208 cancelled by 42668617719 on b183c64; the same happened again today on bb178d3, runs 42816742704/42816969540).

Fix: only a new head commit cancels the runs of a pull request in progress:

cancel-in-progress: ${{ github.event_name == 'pull_request' && github.event.action == 'synchronize' && github.run_attempt == 1 }}

run_attempt == 1: a rerun keeps its run's event, so rerunning an older commit's synchronize run would otherwise cancel the run on the head commit (Sourcery finding). Runs for other actions, and reruns, wait for the run in progress instead, and a waiting run that is replaced never starts a job (no check run at all). A cancelled run then only ever tests an old commit, whose failed gate blocks nothing. The gate keeps if: always() and stays fail-closed: a needed job that failed or was cancelled (timeout, fail-fast, by hand) still fails it.

Not chosen: if: ${{ !cancelled() }} on the gate (suggested in the issue). It skips the gate in cancelled runs, and GitHub counts a skipped required check as passed, so a run cancelled by hand (or replaced by a newer one that hasn't reported yet) would allow the merge without tests. The first version of this branch did that; the adversarial review rejected it.

Changes:

• .github/workflows/ci.yml: the new cancel-in-progress; the gate keeps always().
• actions/gate/README.md: the usage example now includes the concurrency block; new section "Cancelled runs" (why always() and not !cancelled(), runs cancelled by hand or by rerunning an older commit's run, the cost: after a non-push event the result comes after up to two runs); the Tests section.
• tests/gate/test.sh: checks that the gate job of ci.yml and of the README's example runs always() (job-level if: only, with parser self-tests) and that both use the new cancel-in-progress.

No file that callers run changes (actions/gate/action.yml, check.sh are untouched), so per RELEASING.md this needs no release; it appears in the notes of the next one.

Closes #72

Part of #70; the callers follow in #73.

Verification

• pre-commit run --all-files (all hooks; markdownlint-cli2 v0.24.0 run separately via npx because nodeenv fails locally): passed.
• bash tests/gate/test.sh, tests/pr-title, tests/labels, tests/publish-release, tests/release: all passed.
• Mutation check: reverting the gate to ${{ !cancelled() }} or cancel-in-progress to ${{ github.event_name == 'pull_request' }} in ci.yml makes tests/gate/test.sh fail.
• How GitHub applies concurrency shows only in real runs; the claim that a replaced pending run leaves no check run matches cloud-registry-ui run 42816969540 (cancelled, 0 jobs).
• CI: all checks passed (Lint, Test, CI passed, CodeQL, Sourcery) on fdbdb10, run 42862438714.
• Sourcery: 3 threads; 2 fixed in fdbdb10 (reruns cancelling the head's run, test scoped to workflow-level concurrency), 1 answered (a failed gate on an old commit is intended and blocks nothing); all resolved.

Rollout

The callers set cancel-in-progress in their own ci.yml, so a pin bump changes nothing for them: each needs a one-line change of cancel-in-progress to the expression above (their gates already run always()). All pin actions/gate@743e82d… # v1.0.0:

Repo                           PR types                              cancel-in-progress now
Pubgrade                       opened, synchronize, reopened, edited  event_name == 'pull_request'
Pubgrade-Sidecar               opened, synchronize, reopened, edited  event_name == 'pull_request'
TESK                           opened, synchronize, reopened, edited  event_name == 'pull_request'
biohackeu26-ga4gh-sdk-upgrade  default                                event_name == 'pull_request'
cloud-components               opened, synchronize, reopened, edited  event_name == 'pull_request'
cloud-registry                 opened, synchronize, reopened, edited  event_name == 'pull_request'
cloud-registry-ui              default                                event_name == 'pull_request'
docs                           opened, synchronize, reopened, edited  event_name == 'pull_request'
foca                           opened, synchronize, reopened, edited  event_name == 'pull_request'
landing-page                   opened, synchronize, reopened, edited  true (also cancels push runs)
nvflare-wes-testbed            default                                event_name == 'pull_request'
protes                         opened, synchronize, reopened, edited  event_name == 'pull_request'
tesk-api                       opened, synchronize, reopened, edited  event_name == 'pull_request'
tesk-core                      opened, synchronize, reopened, edited  event_name == 'pull_request'
token-exchange-flow-testbed    default                                event_name == 'pull_request'
trs-filer                      opened, synchronize, reopened, edited  event_name == 'pull_request'

cloud-registry and protes (tests/test_workflows.py) and trs-filer (tests/test_config.py) assert the gate's if: always(), which stays valid; their docs/development.md describe the gate. This PR doesn't change any of them.

Declined review findings

• Quality review: "the awk parser is more complex than what it protects" — kept, but simplified (indent via match, own fixture file, job-level if: only) because a grep can't tell a job-level if: from a step's (adversarial finding, round 1).
• Adversarial review, round 1, finding 3 (timeout and cancelled()): moot, the gate keeps always().

Open questions

None.

🤖 Generated with Claude Code

https://claude.ai/code/session_011FSoqMpmDCfbACLj3uy6xV